Bug

In test.py, the KeyboardInterrupt handler does:

except KeyboardInterrupt:
    sys.exit(signal.SIGINT)

signal.SIGINT has the integer value 2. So this is equivalent to sys.exit(2) — a plain non-zero error exit. This is incorrect because:

• Shells (bash, zsh, etc.) use exit code 128 + N to indicate a process was killed by signal N. For SIGINT, the expected exit code is 130 (128 + 2).
• CI runners (GitHub Actions, etc.) inspect exit codes to determine if a job was cancelled/interrupted vs. failed with an error. An exit code of 2 is treated as a generic error, not an interrupt.
• Pipeline chaining — if this script is part of a shell pipeline, the wrong exit code means $? and set -e behave incorrectly.

Fix

Reset the SIGINT handler to the OS default and re-raise the signal. The OS then terminates the process with the correct exit status (130) automatically:

except KeyboardInterrupt:
    signal.signal(signal.SIGINT, signal.SIG_DFL)
    os.kill(os.getpid(), signal.SIGINT)

This is the idiomatic Python pattern for correct SIGINT propagation (referenced in Python docs and PEP recommendations).

Impact

This is a correctness bug that affects CI behaviour — on Ctrl+C or SIGINT from a test runner, the script exits with code 2 (error) instead of 130 (interrupted). This can cause CI pipelines to report a test failure instead of a cancellation.